• 专利附录
  • 专利说明
  • 权利要求
  • 类似技术
  • 同族专利
  • 引用文献
  • 法律状态
  • 优先权
    • 专利摘要:
    The system executes services by a so-called "server" application for at least one so-called "client" application. A preliminary step (40) establishes a list of available server services, parameterized for the at least one client, step (40) in which a releasable process time of the server for said at least client is determined per called code execution cycle. MIF. The system creates at startup: - (41) NT execution tasks for said at least client, each with a priority level of execution and an average execution time allocated, NT being equal to or greater than 1, the sum of the durations said tasks being less than or equal to said releasable processing time; - (42) execution rules associating each of said tasks with at least one service of said list; then, during each MIF cycle (43, 44, 45), the system executes said services on their associated tasks, a task being executed according to its priority level and for a duration at most equal to its allocated average execution time , the unexecuted part of a service being executed in the next cycle on its associated task.
    公开号:FR3021108A1
    申请号:FR1401108
    申请日:2014-05-16
    公开日:2015-11-20
    发明作者:Francois Coulmeau；Laurent Castet；Laurent Deweerdt；Frederic Sanchez
    申请人:Thales SA；
    IPC主号:
    专利说明:

    [0001] BACKGROUND OF THE INVENTION The present invention relates to a method for executing services, in particular flight management, as well as a system for implementing services in real time, in particular flight management and a real-time system using such a method. such a process. The invention applies in particular in embedded systems and more particularly in avionics systems. Each real-time avionics system is architectured and developed to meet performance requirements (failure rate and quality of service in particular) within a framework of defined job. Each system, connected to other systems, consumes data and services made available by the other systems and produces service data for the other systems. These interactions are usually statically fixed during the development of the overall "system of systems" architecture, that is to say when allocating operational functions to physical systems. Thus, it is common in the avionics world to have several dozens of systems meeting all the functions of the aircraft. Typically the aircraft operations are allocated to the systems according to a logical structure, defined in the normative document of the Association ATA (Air Transport Association). The aircraft architecture is therefore declined in collaborative avionics systems, each having a specific function, and interactions with other systems to make the operational service expected. The various functions are distributed over several physical computers, according to aircraft manufacturers' choices, to guarantee mission performance. Embedded systems are qualified, with a demonstrated level of performance, for a given environment. The interactions between systems are defined a priori during the development of the aircraft architecture, and the systems are developed and adjusted to meet the strict need for interaction. If we take the point of view "client-server" where a set of 35 so-called "client" systems make requests to a particular system called "server", the work of manufacturers who develop the functions allocated to the "server" is to guarantee that the final performances of this one will be in conformity with the expected performances and this in the framework of use defined a priori.
    [0002] In this framework defined a priori, all customers are known and well identified, no new client can interact with the system without requalification of the entire system. A major problem is that adding a new client to a given system results in a very expensive requalification. It is necessary to demonstrate again the performance of the operational performance of the entire "server" system, even when no new service is expected by the "server" system. This constrains the evolution of aircraft operations. There is therefore a need to be able to allow the addition of new connections and new customers to a real-time "server" system, by guaranteeing a quality of service and a response time that does not degrade its performance and does not give rise software or hardware modifications of the "server". In this case, the addition of a new client or a new connection would only result in a qualification of the client in question and a demonstration that the network performance remains in compliance with the required requirements. An object of the invention is in particular to meet this need. For this purpose, the subject of the invention is a method of real-time execution of services by a so-called "server" application for at least one so-called "client" application, a preliminary step establishing a list of server services available for said at least one "client" application. client, a step in which a releasable processing time of the server for said at least one client by code execution cycle called MIF is determined, said method creating at startup: NT client tasks (Task (i)) for said at least client with each of them has an execution priority level (P_task (i)) and an allocated average duration of execution (T_task (i)), NT being equal to or greater than 1, the sum of the durations of said tasks being less than or equal to said releasable treatment; execution rules associating each of said tasks (Task (i)) with at least one service (Serv (k)) of said list; then, during each MIF cycle, said method executes said services on their associated tasks, a task being executed according to its priority level and for a duration at most equal to its allocated average running time (T_task (i)) , the non-executed part of a service being executed after the intrinsic tasks of the server. During each MIF cycle, said client tasks are executed for example after the tasks of the high priority server and before the intrinsic tasks of the server. If the number of clients is greater than 1, a task (Task 1) supervises for example the asynchronous requests issued by the clients and triggers the processing of associated services on the server, or on this same task (Task (1)) or on a task of different priority, depending on the available server time within a MIF cycle. In one possible embodiment, the method determines the maximum time required to execute a server service for a client on an associated task, knowing its average processing time per cycle, said maximum duration being transmitted to said client. A maximum execution time being imposed, the execution of a service is for example accepted or refused according to the maximum time necessary to complete the execution of said service and the maximum execution time imposed, the maximum duration of the service. imposed enforcement that may be provided by the requesting customer. Said imposed maximum execution time is for example predetermined by configuration of the server. The average execution time allocated per MIF cycle (T_task (i)) is, for example, defined individually for each client, whatever the associated service. A task (task) is for example defined for each service. For example, a task (task) is defined for each client. The average execution time allocated per MIF cycle is, for example, adjustable according to the specific needs of server execution. The average execution time allocated per MIF cycle is for example adjustable according to the time remaining for the server to perform an internal service, said service not being on said list, and the expected response time for said service. . The releasable processing time is for example equal to a.Ticeopt-b, where a is a coefficient between 0 and 1 and b is a heel duration, Ticeopt being the average duration of the remaining free time per MIF cycle making it possible to hold the response time of intrinsic tasks of the server with a predefined probability. In a particular mode of implementation a = 1 and b = 0. Said available services are for example advantageously structured using an abstract syntax for setting in the form of parameter 10 the server data and said available services. The invention also relates to a real-time system implementing the method described above, comprising at least one physical module where the server is located, the clients being external applications located in said physical module, said clients communicating with the server via a memory internal to the module. The clients are, for example, external applications distributed in other physical modules and communicating with the server via a network protocol. The server is for example a flight management application, the customers interacting with the flight management application. Other characteristics and advantages of the invention will become apparent with the aid of the description which follows, given with reference to the attached drawings which represent: FIG. 1, a presentation of the functional architecture of an on-board flight management system ; Figures 2a and 2b, operating characteristics of real-time systems; Figure 3, an illustration of the principle of the invention; Figure 4, various possible steps for carrying out the method according to the invention; FIG. 5, an example of determining the optimized average duration of the time remaining in a code execution cycle; FIG. 6, the result of a measurement for the determination of the aforementioned average duration; - Figure 7, a law to determine the probability of holding an operating requirement; FIG. 8, a theoretical distribution of the average duration of the remaining time over all the code execution cycles; Figure 9, an example of processing asynchronous incoming requests issued by the clients; FIG. 10, an example of execution of a step of the method according to the invention making it possible to process the tasks entangled between client tasks and server tasks; FIG. 11, an example of a physical representation of the clients in the case of application to an FMS system; Figure 12, an example of language applied to family services "flight management". Figure 1 shows the functional architecture of an onboard flight management system, called FMS (Flight Management System). This standard architecture, well known, meets the ARINC 702A standard. One of the functions of the FMS is to locate the aircraft using its sensors 171 (inertial units, GPS, radio beacons in particular). This function is performed by a location module 170. The system comprises the following functions and components: A FPLN 110 flight function, to enter the geographical elements constituting the skeleton of the route to be followed (departure and arrival procedure, points passages ...); - A NAVDB 130 navigation database, to construct geographic routes and procedures from data included in the bases (points, tags, interception or altitude bequests ...); - A performance database, PRF DB 150, containing the aerodynamic and engine parameters of the aircraft. A lateral trajectory function TRAJ, 120: to build a continuous trajectory from the points of the flight plan, respecting the airplane performances and the confinement constraints (RNP); Prediction function PRED, 140: to build an optimized vertical profile on the lateral trajectory; A guiding function, GUID 200, to guide the aircraft in its 3D trajectory in the lateral and vertical planes, while optimizing the speed; Linking digital data DATALINK, 180 to communicate with the control centers 181 and the other aircraft From the geographical information contained in the navigation database 130, the pilot can build his route, called the flight plan and including the list of waypoints called "waypoints", function provided by the flight plan function 110. The FMS can manage several flight plans. One of them, known as "Active" in ARINC 702A, refers to the flight plan on which the airplane is guided. There are work flight plans, sometimes called "secondary flight plans" or "inactive", as well as transient flight plans. The function 120 calculates the lateral trajectory according to the geometry between the points of passage, commonly called LEG, and / or the altitude and speed conditions which are used for the calculation of the turning radius. On this lateral trajectory, the FMS optimizes a vertical trajectory, in altitude and in speed, passing through possible constraints of altitude, speed, time, by using a modeling of the aerodynamic and motor performances contained in the database of performances 150. Knowing the location of the aircraft and the 3D trajectory, the FMS can enslave the aircraft on this trajectory, this servocontrol being carried out by the guidance function 200. All the information entered or calculated by the FMS is grouped on display screens or other HMIs 10. The communication with the ground, in particular with the airline and the air traffic control, is carried out by the digital data link 180.
    [0003] In the FMS terminology, the term "revision" is used to characterize an insertion, modification or erasure of data from the FMS system, the word edit being also used. In current architectures (irrespective of the aircraft), the part "Flight Planning" and "optimized trajectory" is generally included in a dedicated computer called "FMS" for "Flight Management System" (or flight management computer). ). These functions are the heart of the FM business. This system can also host part of the "Location" and "Guidance".
    [0004] To ensure its mission, the FMS is connected to many other computers (a hundred). Two large customers usually interact with the FMS system: - The Human Machine Interface (HMI), which allows operators (crew) to interact with the FMS - The CMU interface (for Communication Management Unit) that allows a ground operator (airline, air traffic control) to interact with the FMS: This CMU calculator is a customer of the FMS data and can request the modification of the mission (ie insert "revisions" in the FMS ) "Interaction" means "request" sent to the FMS, with an expected return, as opposed to the "information" that third-party systems subscribe to periodically or event-driven data from the FMS.
    [0005] Future operations in the aircraft will however require that third-party systems interact with the FMS, namely: - By using existing public services - By using existing private services - By using new services to implement in the FMS 25 We can quote for example: - Initialization of the FMS flight plan by an external computer (tactile tablet, lpad, EFB for "Electronic Flight Bag") - Integration of the "flight plan" of the FMS with the "running plan" of the taxi calculator (called ANF for Airport Navigation 30 Function, AOF for Airport Onboard Function or TAXI or AMM for Airport Moving MAp) - Optimization of the mission, called by a ground client (company tool for example) or edge (tablet, EFB) via requests FMS calculation - The update of the FMS software (in particular its navigation databases, with 28-day cycle) by third party equipment (tablet, maintenance tool, EFB) - Use of request FMS by a system of monitoring the terrain of the traffic, the weather to filter alerts, or confirm them, or optimize lateral and vertical adjustments (eg: avoidance of a moving cloud mass detected by a weather radar) o the system traffic surveillance is known by the acronym TCAS (Traffic Collision Avoidance System) or Traffic Computer o The field monitoring system is known by the acronym TAWS (Terrain Avoidance Warning System) or GPWS (Ground Proximity Warning System). weather monitoring is known by the acronym WxR (Weather Radar) - Using FMS queries to help trigger events on a third party system (eg: Changing the radio frequency by the RMS (Radio Management System) when we approach to a point of change of region. - Verification of conformity of the lateral and / or vertical trajectory calculated by the FMS, compared to digitized aeronautical charts provided to the crew (stored in a tablet, an EFB for example) - Use of the FMS system to know predictions on a given time horizon according to modes of conduct of the flight (guidance) and airplane status defined (ex: Autopilot wishing to know the average rate of climb on 2000 feet of altitude evolution with 1 engine out of fuel; wishing to compare the average consumption with the FMS consumption predictions ...) - Interactions with the FWS (Flight Warning System) to present verification results, propose automated DO LIST launches, directly modify FMS states on confirmation of faults. - Passengers connected via their cabin interface (IFE for In Flight Entertainment), wishing to know the predictions in time, speed for their destination - Use of the FMS via an AID (Domain Interaction Agent) or an integrated IHS (Interface Homme Système) which focuses and organizes exchanges between computers. Thus, a dozen new customers are likely to interact with the FMS (EFB, WIMS, TCAS, TAWS, WxR, PA, FQMS, IFE), in short most of the different ATA systems. In the future, it is possible that even more customers want to interact with "flight management". However, we do not know a priori the rate of the requests of the different systems, nor the time when the request will be requested, nor the volume of data that this represents. If the third party systems wish to store calculation results for future use, the number of requests of this type is not known a priori. If a new system connects, we do not know a priori its intentions (type of requests, periodicity) The method according to the invention, described later, by making the architecture of the system more open allows the addition of these new clients with an unknown number of queries arriving at random times, while ensuring the intrinsic performance of the system. The invention is described for an avionics system, but it is applicable to any embedded real-time system architecture. Figures 2a and 2b show operating characteristics of these systems. FIG. 2a shows a frame executed by each processor of a computer, this frame being known by the term MIE 10 3021108 according to the Anglo-Saxon expression "Minor Frame". More particularly, each processor executes its code over successive time slots, these slots being MIFs. Each MIF is divided statically or dynamically, according to the technologies, into time partitions, that is, time slots 20 on which a function executes. In the example of FIG. 2a, the MIF comprises N slots P1, P2, P3 PN. This technology is widely deployed on so-called IMA ("Integrated Modular Avionics") modules in aeronautics. It allows to host on 10 the same physical computer several functions resulting in gains in mass and electrical power. In most embedded real-time systems, partitioning is static to ensure the determinism of overall system response times. In the same way, the IMA modules allocate, in a static manner in general, the RAM and ROM physical memories that each function will use. This makes it possible to segregate the various functions that run within the same module and better control the problem of faults. Figure 2b illustrates the real-time execution of a real-time function at a partition of a MIF. FIG. 2b represents a succession of treatments 22 classified by priorities, the processing As2 being able to execute before the processing As1 but being able to be interrupted by As1 taking control because its priority is higher, and likewise for Asi-1 compared to in Asi. In general, the system begins by performing the so-called "cyclic" processing 21 of the function. These are processes that must be executed at each MIF without being interrupted, such processing including input and output management or the calculation of information that must be refreshed at each cycle. These treatments have a higher priority because you have to guarantee that they will have time to run all the time.
    [0006] These are in fact tasks like the others, but they have generally been associated with high priority to ensure that they pass before the other treatments. After the cyclic processing 21, come the asynchronous processing 22. In real time, these are processes that run on request (events, periodic alarm ...). Events are typically generated by the peripheral systems connected to the main system. They are ordered by treatment priority. Thus, in FIG. 2b, a succession of asynchronous processes 21 is displayed, the event As1 being followed by the event As2, which is followed by the event As3 and so on until the last event Asn. If we note P (Asi) the priority of an event, it comes: P (As1)> P (As2)> P (As3)> P (Asn). If the first As1 processing requires all the calculation time remaining on the MIF, the other treatments can not run at best on the next MIF. If the sum of the cyclic processing 21 and asynchronous processing 22 to run does not exceed the duration of the MIF, there remains free time 29 that is called IDLE. The response times perceived by the outside of the system, that is to say perceived by the peripheral systems or by the human, for a given overall treatment, are therefore proportional to the number of MIFs necessary to perform the entire treatment. . Thus on an MIF of 80 ms where the cyclic processing takes 30 ms, if a processing requires 1 second of processor time to execute its computation, it will need at best 20 MIF to finish it, 20 MIF corresponding to 20 x 50 ms = 1 second where 50 ms is the time remaining in a MIF after the 30 ms cyclic process. The response time will be 20 x 80 ms = 1.6 seconds. If the treatment competes with other higher priority asynchronous processing, the number of MIFs needed increases and therefore the response time perceived by the outside. This shows in particular that the challenge for the industrialists of the field to build a real-time architecture is to schedule the processing on priority tasks adapted to take all the response times of the required treatments, taking into account the competition of treatments with a probability of compliance. In general, systems must ensure that they meet their performance requirements 100% of the time, in "single-event" mode, that is, without overlaying competing events. And we measure the probability that this is no longer the case in competing "multi-events", this probability having to be as low as possible. We can thus demand that the system be sized to hold all the response times in 99% of the time. This probability may also be different between the treatments according to their criticality, that is to say according to their impact on the overall performance of the operation. When we know the number of clients that can request asynchronous processing, the maximum frequency of their requests and the calculation CPU duration corresponding to the processing of requests by the server, there are known techniques of the state of the art. to create and schedule the real-time tasks of a given resource, to meet these response time requirements with the required probability. The invention advantageously utilizes a dynamic priority task mechanism as described above, using the measured mean free time, i.e., the average time of the "IDLEs". It must of course that free time 29 exists, that is to say that the system is not dimensioned to the fair, but with the margin. This is in practice the case for most real-time systems because the performance requirements to be achieved are difficult to measure a priori, the intrinsic performance of a system being difficult to measure a priori. As a result, the systems are in practice a bit oversized to take into account hazards and risks. This margin corresponds to the remaining average time 29, i.e. the average duration of the IDLE, when performing system performance measurements over a broad spectrum of computational load scenarios. This remaining average time can be: Measured by test campaigns, for worst cases of event overlay or by massive random tests using Monte Carlo techniques, other types of tests being possible; Quantified by real-time compliant modeling, MBDE tools (Model Based Driven Engeering) sometimes offer performance calculation functions; 30 Measured by test feedback in operational operation. It is thus possible to determine, knowing the system in its field of use, with its determined number of clients, the variables M (IDLE) and P (IDLE) respectively corresponding to the average and the variance of the duration of the task IDLE, that is, the remaining time 29. FIG. 3 illustrates the principle of the invention. According to the invention, an optimized average duration of the IDLE 29, called TIleOpt, is determined whose value makes it possible to hold the response times with the required probability. The system then allocates to external clients a time slot on a new high priority task 31 whose duration does not exceed the duration Ticueopt on a given resource. The new remaining time 29 'becomes less than the remaining time 29 without introduction of this task 31, or even zero. An external client is an unexpected client when developing the architecture, that is to say a new client, not known a priori.
    [0007] The invention thus makes it possible, knowing this TIleOpt time, and knowing the average CPU time of a unit processing 21, 22 among the services offered, and the state of the query stack being processed and waiting, of estimate the deadline by which the server can respond to the client. This makes it possible to have strategies for refusing and taking requests into account according to the deadlines requested by the customers. Implementation variants are possible, in particular: Rather than a single task, N tasks can be created, N being then greater than 1, with different priorities and execution times, to divide the services whose time calculation or importance differ. These N tasks are executed after the cyclic processing 21, for example between this cyclic processing and the first asynchronous processing As1 (FIG. 3 illustrates the case where N = 1); The N tasks can be distributed over several resources, that is to say on several execution instances of the server system, typically in the case of redundant systems. A supervision system must be put in place to allocate client requests to the different physical instances in order to optimize the overall load. It should be noted that in terms of implementation, in an avionics avionics system, the ARINC 653 standard, a real-time task can be performed in part with a given priority and partly with another priority, since the standard allows for assign a task based on a basic priority and a current priority. Other types of implementations are of course possible, especially in non-avionics domains.
    [0008] FIG. 4 presents various possible steps for carrying out the method according to the invention. The method comprises an initialization step 40. This step is performed once. The purpose of this initialization step is to determine the TIleOpt optimized mean free time that will be used by the other steps of the method. In this initialization step 40, a high priority task of given duration is created and its impact is measured on the performance of the intrinsic performance requirements. Several solutions are possible to determine this duration.
    [0009] Figure 5 illustrates an example of determining the Ticeopt time. The desired duration is obtained by an iterative calculation whose steps are presented in FIG. 5. A first step 51 consists in carrying out a campaign of measurements of the intrinsic response times of the system, on a set of representative scenarios, or by modeling the performances of the server system. In this step of initializing the calculation, one does not create a high priority task. We have at the beginning of the chains of treatments on which carry contractual requirements. These requirements, as NB_contract, are characterized by: - A processing chain {E (i), S (i)} between 1 triggering event E (i) and an expected output S (i) - A time requirement of answer T_contract (i) - A probability of meeting this requirement P_contract (i) This campaign measures: - end-to-end response times of a processing chain (called functional chain), on which a contractual performance requirement - The total time of the IDLE remaining between the end of the processing and the expiry of the T_contract (i) contract.
    [0010] Thus, for each string {E (i), S (i)} (i = 1 .. NB_contract), N_mes (i) measurements and / or operational operation tests and / or modelings are available. For each measurement j (j going from 1 to N_mes (i)), of a processing of a chain {E (i), S (i)}, we note the response time obtained "T_mes (i, j) Corresponding to the time between the beginning and the end of the processing, and the total time of the IDLE "T_IDLE (i, j)" The asynchronous tasks of the server use all the available time possible by MIF, until the end of the processing as shown in Figure 6 which shows the result of a measurement j on a chain {(E (i), S (i)). The Nie 'and last MIF, denoted MIF N, corresponding to the end of the treatment thus has a little IDLE, the previous ones being full. Each MIF having a duration T_MIF allocated to asynchronous processing (ie by subtracting the duration taken by the cyclic), for each measurement j of the string i is known: - The number of MIF N_MIF (i, j) to execute the processing is defined by N_MIF (i, j) = T_mes (i, j) / T_MIF, rounded up to the integer The number of MIF corresponding to the expected response time is also known: - N MIF contract (i) = T_contract (i) / T_MIF The next step 52 compares the holding rate of the intrinsic performance requirements with the contractual commitments. In this step, it is a question of checking the statistical distribution of the measured samples, compared to the associated requirement. Many techniques exist. For a real-time system, where the passage in the processing chains will be very important during the life of the system, one can use the properties of the law of large numbers to estimate the statistical law followed by each chain of treatment. For this, the method calculates the average duration and the standard deviation of the measurements of the first step 51, for each treatment chain of the measurement campaign, and determines the percentage of requirements held: For all i ranging from 1 to NB contract, one calculates: - Average duration for a chain {E (i), S (i)}: Tmoy (i) = Ninles (i) es (i) T_mes (i, j) - Standard deviation on the duration, for a string {E (i), S (0): N_mes (i) 1 N _mes (i) (Tmesum - Tmoy (0) 2 - The average duration of the available IDLE: N_mes (i) 1 Tmoy_I DLE = N _mes (i) T _IDLE (i, j) If the number of measures is large enough, the law of large numbers can be used, it allows to affirm that the distribution of the N_mes (i) measures converges in probability towards a law. If the random draws are of the Monte-Carlo type, that is to say if the draws where the input random variables are independent and identically distributed, the "central limit theorem" shows that the distribution of the prints is because characteristics of a particular law, a "normal law", of parameters Tmoy (i) and a (i). These same Monte-Carlo techniques make it possible to determine the minimum size of the sample "N_mes_min (i)" of measurements, ensuring that the error e (i) between the estimated parameters Tmoy (i) and o- (0. and the reality Trep (i) and oTep (i) is less than a threshold of probability Threshold (i): - The threshold Threshold (i) follows the quantiles of the reduced normal distribution, so for Threshold (i) = 32%, q = 1 (1 = 68% of the normal distribution) o Threshold (i) = 5%, q = 1.96 (1.96 a- corresponds to 95% of the normal distribution) o Threshold (i) = 0.3%, q = 3 (3 a- corresponds to 99.7% of the normal distribution) - We have: e (i) <e (i) 1N_mes_min (i) By drawing the normal law Tmoy (i) and a (i) as illustrated in Figure 7, the probability of holding the requirement P_mes (i) can be determined, which is the half-quantile greater than the time T_contract (i). corresponds to the area 71 to the right of the response time T_contract (i) The holding probability P_mes (i) is equal to the area to the left of T_contract (i).
    [0011] A branch 50 of the method verifies all the performance requirements. For i ranging from 1 to NB_contract, we check the condition P_mes (i)> P_contract (i). The condition is met if all the unit conditions are met. In this case, proceed to the next step 53 of the process. If the condition is not met while Tueopt = 0, there is no margin for the high priority task. This is the end of the process. The third step calculates the time margin and determines the duration Tidieopt. Since the probability of meeting the requirements is greater than the contractual requirements, the remaining IDLE averages for each Tmoy_IDLE (i) chain are positive. They correspond to the unused time, which makes it possible to satisfy the T_contract (i) response time requirement. The "IDLE" that can be released for the chain {E (i), S (i)} by MIF, is therefore the average time of the IDLE for this chain, distributed over the number of MIEs of the contract. requirement of this string: TmoyDDLE (0 - 11.17 l) = N_MIF_contract (i) If this time is blocked on each MIE, then for the chain {E (i), S (i)}, the distribution is theoretically of Tmoy_IDLE (i) on the set of the MIE as illustrated by FIG. 8, with the theoretical measurement j obtained on a chain {E (i), S (i)}. In this figure, all available IDLE has been used to place new high priority tasks 31. The processing time is therefore closer to the contract time, and this therefore indirectly increases the probability of failure to meet the performance requirements. Given the impact of a measure on the average results observed for other channels, it will be necessary to complete the steps of Figure 5 to converge on optimal times. The fourth step 54 performs a measurement campaign with saturated high priority task. More specifically, in one embodiment, only a high priority task is created. The duration of this task can therefore not exceed the smallest possible releasable time, ie the time corresponding to the most constrained string: ^ il ^ - TIdleopt = MiniE [1; NBcontractl Tldle Opt (This embodiment can to be a little too constraining, if the releasable values are very small for a given chain and larger for the others Advantageously, the process creates "NT" Tasks Task (1), Task (NT), and groups the processes {E ( i), S (i)} by homogeneous releasable IDLE duration: - T Let _ _ _ _ miniE [1; NBcontractind1eopt (i) and TIdleoptmax = MaXiE [1; NBcontractlTldleopt (i) - Note AT = (T ' -ldleoptmax Tldleoptmin) INT - Task (1) gathers the treatments {E (k), S (k)} for k ranging from 1 to Nb_contract such that the average releasable duration Tuueopt (k) is between [Tkueoptmin; Thueoptmin + AT ] - Task (i): gathers the processes {E (k), S (k)} for k ranging from 1 to Nb_contract such that the average releasable duration Thueopt (k) is understood between [Ticueoptmin + (i - 1) * AT; TIleoptmin + * An - Task (NT): gathers the processes {E (k), S (k)} for k ranging from 1 to Nb_contract such that the average time that can be released Tuueopt (k) is between [Tnueoptmin + (NT - 1 ) * AT; T-Idleoptmin + NT * AT] Any other division can be performed to group treatments, 20 without changing the inventiveness of the process. The next step 55 performs an identical measurement campaign at the level of the scenarios played in step 51, but by blocking for each MIF a processing time per string {E (i), S (i)} equal to the associated T IdleOpt The second step 52 is then restarted to perform the measurements on the response times obtained in this fifth step 55. The second branch 60 of the process following the second restarted step 52 consists in checking the probability of holding the response times. by computations identical to the first branch 50. For i ranging from 1 to NB_contract, the condition P_mes (i) = P_contract (i) is checked to within tolerance (1% for example). if all the unitary conditions are fulfilled, in this case, we go on to an end step 57 which will be described later, otherwise we will not be able to verify all the conditions of the branch, we move on to a next step 5 6. The latter 5 adjusts the average values according to the results obtained. Two cases occur for each treatment {E (i), S (i)}: - Case 1: There is still some margin left for the treatment. The IDLE margins are slightly increased for the chain in question: Ticueopt (i): = k * Tune0pt (0, with k slightly greater than 1 (for example 1.1)) - Case 2: There is no time for treatment. The IDLE margins for the string in question are slightly reduced: TIleopt (i): = k * Tuueopt (i), with k slightly less than 1 (for example 0.9) Step 56 then loops back to the fourth step 54 The steps 54, 55, 52, the second branch 60 and the step 56 are repeated until the conditions of the branch 60 are filled in. The last step 57 determines the total total time allocated to the "Ttotalclients" clients per cycle of calculation of a MIF of duration T_mif "Ttotaldients" represents the releasable processing time of the server for the tasks 31. If the Tulleopt are non-zero, that is, to say if there is room for treatment: - all clients = a st a percentage (between 0 and 100%), and "b" is a stub duration. This ensures that - Ttotalclients TIdleopt The values "a" and "b" are calculated to adjust the margin, if necessary.
    [0012] The terminal process Ttota / cuents so that: - Ttota / ciients ... Tmin, (minimum time allocated to customers) In a preferred embodiment, generous for the customer: - a = 1 (ie 100%) and b = 0, andTmin = Thueopt In an alternative, minimalist for the client, one can consider values like: - a = 0,75 (ie 75%) and b = 10% of T_mif, and Tmin = 1% Tniif In a dynamic alternative for the client, we can consider values based on the estimated short-term load of the "server": - a = f (Tjateopt, load) and b = g (Tmif, load), andTmin = h (Tmif) Indeed, for In most real-time systems, it is possible to determine in a sure way the sequence of intrinsic system functions related to an event. Events can also be classified into two types: o predictable event: the system monitors triggering parameters of an event. It knows how to temporally estimate the occurrence of the event in question (typically for an FMS, the system knows how to accurately estimate the occurrence of a sequence of a point in distance, altitude, time) o unpredictable event: it is in question general alarm of the "server" by an external system, or a timeout due, or by a pilot interaction. The system can not predict the occurrence of the event, but at least knows how to estimate the associated computing load. The method can thus perform a dynamic allocation of the adjustment values of the available time according to a rule of the following type: Event type CPU time Time allocated to the customer requirements Process the event Predictable, Y ms Maturity mode at X ms (milliseconds) intermediate: "generous mode" on X ms then "minimalist mode" during the response time to treat the Y ms on this mode, then "generous time" unpredictable Y ms "minimalist mode for the client" Absence 0 ms "generous mode "For example, when the FMS estimates an upcoming peak load, it can temporarily reduce the high-priority time slot allocated to customers because it knows it will need to consume for its needs. intrinsic more than IDLE. As a result of the time allocated to the clients, it is determined in the initialization step 40 the list of services available to the customers. The list includes generic services, such as consulting services and modification services, and business services that depend on the application of the real-time server. Examples of business services have been given previously for a flight management device. According to the invention, in order to further reduce the risk of having to modify the server and requalify it, the list of the services it proposes is made as independent as possible from the application domain, in particular by: the use of a generic syntax for services, independent of the function executed; - the use of parameters, lists, to define the business function; - the use of unbounded lists or of sufficient size for the parameters, so as not to modify the call structure of the service, even when the server is enriched with new functions or new parameters; the use of a language, neutral, based on physics (classical magnitudes of position, speed, acceleration, mass, time especially with regard to the avionics field for example), to have a more generic interface possible. This is an abstract modeling of the interface between the server and the clients, called "server interface". The interface is standard, that is, it does not provide services for a client. A new client that -ro arrives must comply with this interface. Each service in the list is "abstract" and characterized for example by: - its family of origin - a list of parameters - option: a priority level required 15 - option: a required precision - option: a class of processing time The parameters are specified when clients are called from those that are statically defined by "server interface". At the output of this initialization step 40, a table of 20 NB_Serv services is available. Subsequently, each service will be called "Serv (i)" for i = 1 to NB_Serv. For each service, the table contains: - CPU processing time (not published in the "server interface") - "Guaranteed" response time (published in the "server interface") 25 Return to Figure 4. Once the initialization step has been performed, the method performs the following steps, the initialization step being no longer performed for subsequent operations, services and time T - IdleOpt allocated having been defined. The initialization step could again be implemented in case of evolution of certain parameters.
    [0013] The first step 41 performs the initialization of the request stack 49 and the creation of the execution tasks 31. The request stack 49 is initialized to O. In this step, the process creates "TASKS" structures characterized by a number NT of execution tasks, each task i, for i ranging from 1 to NT, being characterized by at least: an identifier task (i); A priority level P_task (i); A duration T_task (i) These are the tasks optimized according to the initialization step 40. The case NT = 1 corresponds to the illustration of the task 31 of FIG. 3. The "server" already has its list. of Tasks Server_Tasks (i), ordered by their priorities P_Server Tasks (i) for i ranging from 1 to NB_Server_Tasks. Typically the highest priority tasks correspond to the cyclic tasks or processes 21 and the lowest priority task is the Server_Tasks task (NB_Server_Tasks) corresponding to the IDLE 29. The priority levels are used to schedule the execution of the tasks: - P_Task (i ) <> Ptask (j) V i <> j, (i, j) e (1 .. NT) x (1 .. NT) - P_Task (i) <> P_Server_Tasks (j), V (i, j) E (1 .. NT) x (1 NB_Server_Tasks) The tasks allocated to the client can be intricated into the "server" tasks, or grouped together. For purposes of implementation using the ARINC 653 standard and its dynamic task priority modification function, it is preferable that they be grouped together to control real time. The T_Task duration of each "Task (i)" task is adjusted so that: - EIM-Tasks T _Tasks (Task (i)) = - T totaicuents - In the case of dynamic durations, it must be ensured that each task Elementary has a minimum duration Tmin. This duration can not be greater than Ttotaiclients / NT while checking Erjasks Tmin (i) <Ttota 1 clients In a specific alternative to redundant resources, corresponding to a case where there is more than one physical instance of the "server", the "TASKS" structure created by the process can be distributed over the different physical resources, the different resources then sharing the NT tasks. In another alternative, the method creates as many "TASKS" instances as there are 10 resources, then there are NT tasks per resource. In a third alternative, the method creates a number of tasks per resource intermediate between the two alternatives above. as illustrated by the example defined by the following table where each resource has a number of tasks between 1 and NT: 15 Task Resource 1 Resource 2 ... Resource i ... Resource NR Task (1) XX Task (2) XXXX Task (i) XXXX Task (NT) XXXX The second step 42 performs the determination of the execution rules of the tasks. This step associates: 20 - "execution tasks" - available services, creating rules. Tables are available for the allocation of services on the tasks, for example according to the following table: Task Service running on task Task (1) Serv (i), Serv (j) ... Task (1) i) Serv (k), Serv (n) ... Task (NT) Serv (p), Serv (q), ... For example, the services can be assigned to tasks by their processing time, as defined in the initialization step 40, that is to say put the most consumer services on a task to which one will allocate a longer execution time, and the unitary services on a task of shorter duration. The services can also be assigned to tasks by nature (modification, consultation) or by priority. In an alternative, we can assign tasks to clients, according to their priority as illustrated by the following table: Client task running on task Task (1) Client_x --- Task (i) Client_y --- Task ( NT) Client_z On the other hand, since we do not know a priori the number of clients that connect, nor their nature, the process includes: - Either a static configuration table, allowing the startup to allocate the clients on tasks by their physical port (that is to say by their physical or logical interface: notion of "Virtual Link" in aeronautics which defines the cabling between systems) - Or an addition in the signature of the calls, which allows a scheduling task to assign them to a client task. A new client can then declare himself with a typical profile (frequency of calls, types of services requested ...) The method, in a preferred implementation, can in all cases mentioned above define the Task (1) (the more priority of the client tasks) as being the scheduler of the requests that arrive at the "server", that is to say, to put them in the stack of requests 49 with the proper task allocation on which it will execute. It will at once have the highest priority of all Task (i). The method can alternatively define a stack of requests by task, the role of the task of order 1 (Task (1)) will then fill the different piles. The method may, in an alternative, select the resources on which the services or the clients will come to connect.
    [0014] Any other combination is possible, without this limiting the scope of the invention. In the third step 43, the priority tasks of the server are executed. More precisely, this step carries out the conventional internal calculations of the server, for its own needs, of high priority, these are in general the cyclic tasks 21. All the server tasks verify the following relation: P_Server_Task (Server_Tasks (j))> P_Task (Task (i)) V (i, j) e (1 .. NT) x (1 .. NB_Server_Tasks) It is in this third step 43 that the processing of a MIF begins, this processing starting with the performing the priority tasks, in particular the cyclical tasks 21, to which the third step 43 is dedicated. 27 3 02 1 10 8 In the alternative dynamic allocation of the time allocated to the clients of the first step 41, the third step 43 realizes for example the calculation of each estimated predictability of an event to occur, e of the estimated treatment load on a fallen event. The next step, the fourth step 44, continues the processing of the MIFs by processing the asynchronous incoming requests sent by the clients 48. It comprises several substeps illustrated in FIG. 9. The first substep 91 consists of recovering a new request Ri coming from a client Ci. This very short recovery step runs on the Task (1) task in a preferred implementation. In an alternative, this support could be done by cyclic processing 21 of the server. The request is supported in the next step 92 if the system knows how to handle it in the allotted time, i.e. if the response time required to process the request is compatible with the minimum possible response time, on the task Task (i) to which it has been assigned, from the initial MIF, this support being: - Function of the start MIF of the calculation of the request Ri 20 - Function of the allocated time for this request T_Task (Task (i)) - Function of the time allocated for this request in time remaining releasable IDLE o In an Arinc 653 implementation, the task that runs on the IDLE (that is, on Server_Tasks (NB_Server_Tasks) is still the highest priority that has not completed its work on its task o In another implementation, the process could cut the IDLE into the same number of tasks as NT and assign a time slot to each of the remaining customer tasks.
    [0015] If the request stack 49 is full, a rejection notification with the status 'Full Stack' is for example issued.
    [0016] In a "multi-resources" alternative, this distribution task is for example executed on one of the resources which distributes the requests on different resources, according to the load of said resources. Thus, if a resource i is busy processing requests and can not absorb a new request in its stack without guarantee of response within the given time, the supervision system is addressed to a less busy resource, if it exists. . The third sub-step 93 is to direct the result of the previous sub-step 92: either to the request stack 49 via a next substep 95, or to another substep 94 of the notification of rejection at client 48, when, for example, the deadline requested by this new client is not compatible with the cumulative duration of the treatments already present and accepted in the stack. This substep 94 is a protocol service with the client to return a refusal status of its request Ri and possibly a sub-status indicating for example a treatment too long, a penalty cell or another state. If the request Ri is acceptable, the substep 95 sends a write request to the request stack 49. In a possible embodiment, the incoming requests are classified in the FIFO stack. Preferably stack 49 is unique, but there may be one stack per task in an alternative implementation. In the sub-step 95, it is therefore written in the stack: the service Serv (i) to execute to fill the request Ri, at the right rank in the stack; optionally, the client Ci at the origin of the request; - optionally, the requested processing time; Optionally, the one or more execution resources chosen, in the "multi-resources" alternative.
    [0017] In the multi-resource alternative, the stack can be managed only by the resource that oversees all requests. Advantageously, a local copy of the stack on all the resources, or a pooling of the stack between the resources can be performed, to avoid the problems of robustness, in the case for example or the supervision resource fails. The fifth step 45 consists of executing, for each resource: the different requests of the stack of requests 49 on the different tasks to which they are assigned; the remaining server tasks; then if there is still available CPU time on the IDLE task, after execution of the server calculations, to execute the remaining tasks according to a priority criterion.
    [0018] FIG. 10 illustrates an exemplary execution of the fifth step 45 that makes it possible, in particular, to handle the intricate tasks between client tasks and server tasks. In a preferred implementation, the Task (1) task is used to fill the stack 49 in the fourth step 44. It can also be used to process the unloading of the highest priority tasks, for the processing of the requests of the stack illustrated by the FIG. 10, the fifth step 45 comprises substeps performed iteratively. The process loops between the first substep 101 and the fifth substep 105 on the client tasks. The first step 101 takes into account the request of order j, j varying from 1 to Nb_tasks and expressing the depth of the stack, if the requests are classified in FIFO. In the second substep 102, the method first checks whether the task of order j, task (j) is free, or taken by the execution of a request which had been accepted in a previous cycle, and which is not finished; If the task is free, the method verifies in the third substep 103 whether it can unpick a request to be assigned to the client task. If it is the case, it unpacks the most prioritized request Ri placed in the stack, this request becomes the new request to be executed during task task (j) in the following substep 104; If the task is free but nothing is to be executed (no request to be unstacked), the task of this substep 104 immediately releases the hand to let the next task run by passing to the next substep 105 This next sub-step 105 consists of checking whether there are asynchronous tasks of the priority server between those of the current client task Task (j) and the next Task (j + 1), if it is the case. these server tasks are executed. This process can be expressed as follows: o There exists i such that P_Server_Task (Server_Tasks (i))> P_Task (Task (j + 1)) where (i, j) e (1 .. NT - 1) x (1 .. NB_Server_Tasks); o We loop 105 on the intrinsic tasks of the server as long as this equation is verified; o Then we loops back to the next client task (j = j +1) by going back to the first sub-step 101 of the execution loop of the client tasks entangled in the server tasks. When all the tasks of the execution loop are completed, a next substep 106 is checked if there is still free CPU time on the IDLE task to execute the remaining client tasks. If there is no free time, the fifth step 45 is completed 108. If there is still free time, the tasks are executed according to a priority criterion, the highest priority task being performed in whole or in part, according to the time available. When the allocated time is consumed or the completion of the task completed, the fifth step 45 is completed. An end of task notification is issued 109. The sixth step 46 manages the transition to the next cycle (next MIF), a cycle being performed from the third step 43 to the fifth step 45. In this step 46, if a processing of the fifth step 45 for an external client is terminated (information transmitted by the end of task notification sent (109), the system: - retrieves the data of the request Ri in the request stack, - notifies the client Ci corresponding with the result of the calculation - Removes the request from the request stack This processing is performed for each of the processes that were completed in the fifth step 45. There may indeed be several completed processes, this information being transmitted by the notification 109 A cycle 43, 44, 45 corresponds to the processing of a MIF as illustrated in FIG. 8. The cycle is repeated as long as the tasks Task (i) created in the first step 41 are not 43, 44, 45 shows, in particular, that when processing a MIF: - Cyclic tasks 21, or high-priority server tasks, execute first; Task (i) client tasks then run for a maximum duration of T_Task (i), so the server does not always have time to complete the current Task (i) client task; The intrinsic tasks of the server are then executed, the intrinsic tasks are generally the asynchronous tasks of a real-time system but can be cyclical tasks of lower priority than the high priority task of the server; - And if there is still time on the MIF, that is to say that the intrinsic tasks of the server have not consumed the entire duration of the MIF, then the task task (i) runs on the server. IDLE, that is, the remaining time of the MIF. Advantageously, via the creation of a task Task (i) of intermediate priority, executed over a duration T. IdleOpt determined beforehand on the basis of the performances of the system, the invention makes it possible: - to allocate calculation time to third-party clients (or external clients), in a guaranteed way; - Satisfy the response times of the server system with a guaranteed probability of meeting the requirements; - To always be able to give a reliable prior answer of acceptance or refusal of support of a request. It follows that: - The performance of the server remains guaranteed, regardless of the number of existing or future clients requesting it, since an "over-solicitation" is executed after the server has completed its intrinsic calculations; The structuring of the services makes it possible to ensure backward compatibility since an abstract syntax has been used, making it possible to put the data and services of the server in the form of parameters. In a preferred embodiment, particularly in the avionics field for flight management, the initialization step 40 and the first step create only one client task 31 distinct from the intrinsic tasks of the server. The task list is then replaced by the single task Task (1), NT being equal to 1 as illustrated in FIG. 3. In the second step 42, all the client processes are then executed on the single Task task (1). ) 31. In the first substep 91 of the fourth step 44, the requests are performed on this single task Task (1) and the fifth step 45 is performed on this task Task (1). The sub-step 105 has no more sort to do since there is only one task Task (1): it thus executes in a block the intrinsic calculations of the server. This preferred embodiment can advantageously be implemented in a system based on ARINC 653. It is also possible to provide that for the initialization step 40 as well as for the first four steps 41, 42, 43, 44, the method creates one task per resource, and all the processing is done on all the resources. There is no optimized task allocation between 30 resources. Still in a preferred embodiment, in the preliminary step 40, there is in the relation: - All clients = Ticueopt b That is to say that the time allocated to the customers per cycle of calculation of an MIE 35 is equal to the optimized average duration of the Tueopt IDLE.
    [0019] FIG. 11 shows an example of a physical representation of the clients in the case of application to an FMS system, of the type notably that described with reference to FIG. 1. The server is a flight management application. The system comprises for example two physical modules 111, 112 forming the physical resources each including a server. In this example, the server is a flight management application. The system being redundant, the two physical resources perform the same functions. The identified and known clients 1, 2, 3 are housed in the physical modules 111, 112, physical modules of the FMS. External clients, not previously identified, can be applications either hosted in the physical modules 111, 112 hosting the server, or distributed applications in the aircraft in other physical modules 113, 114, 115. In the example of FIG. 11, three external clients A, B, C are housed in the physical module 111, and two external clients A and B are housed in the physical module 112. For this purpose, the clients A, B, C have, for example RAM internal modules as physical resources, the client application codes A, B, C being copied to the internal RAM module to which they are connected (111 for A, B, C and 112 for A, B). Other external clients D, E, F, G communicate with the physical modules via an AFDX link, access is through the standardized protocols, ARINC 653, in the example of Figure 11. Clients can be among the following applications: an HMI, an integrated IHS, an AID a CMU a TCAS a TAWS a WIMS or a WxR an EFB a tablet a FQMS a PA a FWS an IFE these applications having been presented during the description of the FMS system of the figure 1. Other client applications are of course possible. With reference to the initialization step 40, the FMS services or functions can be abstracted as described below. Three main service families can be defined to classify all the services of an FMS according to the AEEC ARINC 702A standard. - The services of geographic data consultation (navigation data & dynamic magnetic variation), allow customers to search for geographical information or magnetic declination on a point of the globe; Aircraft performance & performance services using the lateral trajectory 120 and prediction functions 140 and the performance database 150, this family being composed of the following list: aircraft characteristic terminals (eg min and max masses, certified altitude ceiling, etc.) o take-off and landing speeds (so-called characteristic speeds) 20 o flight envelope calculations (max speeds, stall speeds , roll max ...) o integration calculations according to selected aircraft modes (rise of X feet constant thrust, descent with determined air slope and fixed speed, cornering imposed ...) 25 o calculations of packages ( for some FMS, simplified performance calculations can be defined in the DB PERF, where the required accuracy is lower) - flight management services o consultation of the state of the av ion (position, speed, states of the 30 systems connected to the FMS, such as the engine state, the autopilot mode, etc ... o consultation and modification of flight plan and trajectory 5D o consultation and modification of the data of initialization of the flight (capture of takeoff speeds, cruising altitude, forecast weather, fuel consumption modes ...) Taking for example the family "flight management", the typical services 5 are in particular: - Administrative services allowing to copy all or part of a departure flight plan to a destination flight plan, to erase a flight plan, to exchange 2 flight plans etc ... - "Initialization" services to initialize a route and its 10 main parameters - "Departure" services to enter departure procedures - "Arrival" services to enter arrival procedures - "Airways" services to enter the list of "airways" sky) 15 - Alternate services for entering and checking information on alternate airports - "DIR TO" service for DIRECT TO waypoint - Vertical stress capture service (altitude, speed, time) - "HOLD" services 20 - "Meteo" services for entering wind and temperature information during the various phases of flight - "Location" services that make it possible to know the positioning of the aircraft with the different sensors, the accuracy of navigation, the beacons used for navigation, etc. 25 - "Route Summary" services to display a summary of the Route or mission. In the geographic data and performance data services, three types of services can be classified: - "Data" services to display the data related to elements of the navigation database: A service for the stored Routes, a service for "points of passage", a service for "radio beacons", a service for "airports" - "Status" services which give the configuration of the aircraft (Part Number of software and databases, ...). There may be a dozen Services of this type. - "Mass management" services for entering and verifying masses (empty weight, on-board fuel) and the center of gravity Figure 12 shows an example of language applied to family services "fligh management". It comprises three high-level commands that make it possible to make all the services of the family "flight management" units. Parameters PARAM 121 are the unit elements 1211 (physical quantities of the FMS trade) manipulated. Typically: - distance between elements - track (angles with respect to the north) - altitude - speed 20 - fuel - time of passage - wind, - even other information such as: o the quality of the GPS signal at the point, 25 o the temperature , o the navigation requirement, o the min and max limits that can be reached in hours, o the time / speed / altitude constraints ...).
    [0020] The operators IN 122, FOR 123, AT 124, TO 125 are typical of the flight management services of the FMS business. They make it possible to: - specify a destination flight plan for the revision, among the various flight plans managed by the FMS (In), among at least the "active" flight plan 37 3021108, the "temporary" flight plan , the "secondary" flight plan - specify a particular phase of the flight (For), among at least the phases "pre-flight", "take-off", "climb", "cruise", 5 "descent", "approach" - specify a revision on a unitary element (leg or waypoint) of the flight plan, via AT (the revision applies to the element) and TO (the revision ends on the element) 10 The operator DATA 126 is central in the process. It is the transcription of "revisions" of the FMS business, available to customers, by a "given" view (the data or the data structure on which the order will be placed). For flight management services, it is possible to define (non-exhaustive list) the flight plan elements derived from the navigation database 130 or created by the pilot, as described in the AEEC ARINC 424: - Airport ( airport) - Runway - Departure procedure (SID, SID ENROUTE), including decision altitudes (altitude of reduction of the gases, altitude of end of takeoff ...) - Arrivai procedure (STAR, VIA, APPROACH), including Beam capture altitude ... - Alternate Procedure - Cruise FL - Airways - Waypoints (Lat / Long Points) - Waypoint Constraints ( Altitude, Speed, Time, Cruise Steps) - Points created by other points (ATO, PBD, PBPB, Lat / Long) - Overfly (crossing constraint over the point) 302 1 108 38 - Trajectory Stresses ( RNAV, RNP, RVSM) - Hippodromes waiting and turning procedures on one point - Off set (lateral or vertical offset with respect to the trajectory) - Flight plan (complete structure) 5 - 2D trajectory (list of trajectory segments joining the elements of flight plan) - 3D trajectory (2D trajectory + evolution in altitude - Trajectory 4D (3D trajectory + evolution in speed or time) - 5D trajectory (4D trajectory + fuel consonne) 10 - Meteorological data on points or phases of flight But also the elements of airplane performance (from the performance database 150 ), in particular: - Engines - Masses 15 - Take-off configuration (V1, V2, V3, Flaps conf, Trim ...) - Landing configuration The FPLN 127 operator indicates the flight plan on which the revision will be carried out among at least the "active" flight plan, the "temporary" flight plan, the "secondary" flight plan 20 Thus, with this structuring, three CMD 128 commands can be defined to encapsulate all flight management services: - serv ices INIT and VALIDATE cover flight plan administration services - UPDATE service covers all other services (revisions) 25 The structure of services, defining the sequence of services and their interactions, presented in Figure 12 uses a Abstract syntax 128, 127, 126, 122, 123, 124, 125, 121 for setting server data and services as parameters. Advantageously, a standard client interface based on parameters is thus obtained, independent of the specificities of the services, in particular of the business specificities, thereby ensuring the upward compatibility of the new services.
    权利要求:
    Claims (19)
    [0001]
    REVENDICATIONS1. A method of real-time execution of services by a so-called "server" application for at least one "client" application, characterized in that a preliminary step (40) establishing a list of server services available for said at least one client, step (40) wherein a releasable server process time for said at least one client per code execution cycle called MIF is determined, said method creates at startup: (41) NT client tasks (31, Task (i)) for said at least one customer, each having an execution priority level (P_task (i)) and an allocated average execution time (T_task (i)), NT being equal to or greater than 1, the sum of the durations of said tasks being less than or equal to said releasable processing time; (42) execution rules associating each of said tasks (Task (i)) with at least one service (Serv (k)) of said list; then, during each MIF cycle (43, 44, 45), said method executes said services on their associated tasks, a task being executed according to its priority level and for a duration at most equal to its average duration of execution allocated (T_task (i)), the non-executed part of a service being executed after the intrinsic tasks of the server.
    [0002]
    2. Method according to claim 1, characterized in that, during each MIF cycle, said client tasks are executed (104) after the tasks of the high priority server (43) and before the intrinsic tasks of the server (105).
    [0003]
    3. Method according to any one of the preceding claims, characterized in that if the number of clients is greater than 1, a task (Task 1) supervises the asynchronous requests issued by the clients and triggers the processing of associated services on the server, either on the same task (Task (1)), or on a task of different priority, depending on the available time of the server within a MIF cycle.
    [0004]
    4. Method according to any one of the preceding claims, characterized in that it determines the maximum duration necessary for executing a server service for a client on an associated task, knowing its average processing time per cycle, said maximum duration being transmitted. customer audit.
    [0005]
    5. Method according to any one of the preceding claims, characterized in that a maximum execution time being imposed, the execution of a service is accepted or refused according to the maximum time required to complete the execution of said service. and the maximum duration of execution imposed.
    [0006]
    6. Method according to claim 5, characterized in that the maximum execution time imposed is provided by the customer requesting said service.
    [0007]
    7. Method according to any one of claims 5 or 6, characterized in that said maximum execution time imposed is predetermined by configuration of the server.
    [0008]
    8. Method according to any one of the preceding claims, characterized in that the average execution time allocated per MIF cycle (T_task (i)) is defined individually for each client, whatever the associated service.
    [0009]
    9. Method according to any one of the preceding claims, characterized in that a task (31, task (i)) is defined for each service. 20
    [0010]
    10. Method according to any one of the preceding claims, characterized in that a task (31, task (i)) is defined for each client.
    [0011]
    11. Method according to any one of the preceding claims, characterized in that the average execution time allocated per MIF cycle is scalable according to the specific requirements of the server. 25
    [0012]
    12. Method according to any one of the preceding claims, characterized in that the average execution time allocated per MIF cycle is adjustable according to the time remaining for the server to perform an internal service, said service not being on said list, and expected response time for said service.
    [0013]
    13. A method according to any one of the preceding claims, characterized in that the releasable processing time is equal to: a.-rldleopt - b where a is a coefficient between 0 and 1 and b is a heel duration, Tldleopt being the average duration of free time remaining per MIF cycle making it possible to keep the response times of the intrinsic tasks of the server with a predefined probability.
    [0014]
    14. The method of claim 13, characterized in that a = 1 and b = O.
    [0015]
    15. Method according to any one of the preceding claims, characterized in that said available services are structured using an abstract syntax (128, 127, 126, 122, 123, 124, 125, 121) for setting parameter server data and said services available.
    [0016]
    16. Real-time system implementing the method according to any one of the preceding claims, comprising at least one physical module (111) where the server is located, characterized in that the clients are external applications implanted in said physical module, said clients communicating with the server via an internal memory module.
    [0017]
    17. System according to claim 16, characterized in that the clients are external applications distributed in other physical modules (113, 114, 115) and communicating with the server via a network protocol.
    [0018]
    18. System according to any one of claims 16 or 17, characterized in that the server is a flight management application.
    [0019]
    19. System according to claim 18, characterized in that the customers belong to the following list of applications: an IHM an IHS an AID a CMU- a TCAS a TAWS a WIMS a WxR an EFB a FQMS a PA a FWS an IFE 15
    类似技术:
    公开号 | 公开日 | 专利标题
    EP2945062A1|2015-11-18|Method for performing services in real time, in particular flight management and real-time system implementing such a method
    EP2991274B1|2017-02-01|Method for performing services in adaptive real time, in particular flight management and real-time system implementing such a method
    FR3055958A1|2018-03-16|DECISION AID FOR THE REVISION OF A FLIGHT PLAN
    FR3025920A1|2016-03-18|METHOD FOR REAL-TIME CALCULATION OF A PLANNED TRACK, IN PARTICULAR A FLIGHT PLAN, COMBINING A MISSION, AND A SYSTEM FOR MANAGING SUCH A TRAJECTORY
    CA2291865C|2009-04-07|Procedure for setting up an air traffic service unit
    FR3030805A1|2016-06-24|QUALITY OF SERVICE OF A FLIGHT MANAGEMENT SYSTEM
    FR3067802A1|2018-12-21|ALTERNATIVE ROAD MANAGEMENT FOR AN AIRCRAFT
    US20180293687A1|2018-10-11|Ridesharing management for autonomous vehicles
    FR2906921A1|2008-04-11|Three dimensional emergency path providing method for aircraft, involves updating searched path based on changes in environmental conditions according to information provided by on-board sensors and exterior information
    FR2953302A1|2011-06-03|Planning, path calculating, predicting and guiding method for respecting passage time constraint of e.g. aircraft with pilot, involves monitoring current prediction of passage time to signal, alter or control readjustment of profile
    FR2939558A1|2010-06-11|METEOROLOGICAL MODELING METHOD FOR CALCULATING AN AIRCRAFT FLIGHT PLAN
    FR3038750A1|2017-01-13|METHOD FOR INTEGRATING A NEW NAVIGATION SERVICE IN AN OPEN AIR ARCHITECTURE OPEN ARCHITECTURE SYSTEM OF A CLIENT-SERVER TYPE, IN PARTICULAR A FIM MANUFACTURING SERVICE
    FR3021401A1|2015-11-27|RECONFIGURATION OF THE DISPLAY OF A FLIGHT PLAN FOR THE PILOTAGE OF AN AIRCRAFT
    FR3028975A1|2016-05-27|ERROR DETECTION METHOD OF AN AIRCRAFT FLIGHT AND GUIDANCE SYSTEM AND HIGH INTEGRITY FLIGHT AND GUIDE MANAGEMENT SYSTEM
    EP3340208A1|2018-06-27|Management of messages to flight crews
    FR3048773A1|2017-09-15|METHOD AND SYSTEM FOR MANAGING A MULTI-DESTINATION FLIGHT PLAN
    FR3067803A1|2018-12-21|SYNCHRONIZATION OF A DUAL AVIONIC AND NON-AVIONIC SYSTEM
    US20200174848A1|2020-06-04|Integrating multiple distributed data processing servers with different data partitioning and routing mechanisms, resource sharing policies and lifecycles into a single process
    EP3232417B1|2019-11-06|Protection of the sequencing of an aircraft flight plan
    FR3082829A1|2019-12-27|AIRCRAFT MANAGEMENT
    FR3031806A1|2016-07-22|METHOD FOR AIDING NAVIGATION ACCORDING TO WEATHER CONDITIONS
    FR3038751A1|2017-01-13|METHOD FOR INTEGRATING A CONSTRAINED ROAD OPTIMIZATION APPLICATION IN AN OPEN ARCHITECTURE AIRCRAFT SYSTEM OF CLIENT-TYPE SERVER
    FR3043487A1|2017-05-12|AIRCRAFT TRAJECTORY MANAGEMENT IN THE EVENT OF AN ENGINE FAILURE
    WO2008141953A1|2008-11-27|Automated system with deterministic answer times
    FR3072795A1|2019-04-26|METHOD FOR CONTROLLING THE ALERT RETRIEVAL | AND / OR SYSTEM RECONFIGURATION PROCEDURE |, COMPUTER PROGRAM PRODUCT AND SYSTEM FOR CONTROLLING THE SAME
    同族专利:
    公开号 | 公开日
    FR3021108B1|2016-05-06|
    US9967322B2|2018-05-08|
    EP2945062A1|2015-11-18|
    US20150334173A1|2015-11-19|
    CA2888897A1|2015-11-16|
    CA2888897C|2021-06-01|
    引用文献:
    公开号 | 申请日 | 公开日 | 申请人 | 专利标题
    US20020120663A1|2000-06-02|2002-08-29|Binns Pamela A.|Method and apparatus for slack stealing with dynamic threads|
    US20120079486A1|2010-09-23|2012-03-29|International Business Machines Corporation|Integration of dissimilar job types into an earliest deadline first schedule|US10147327B2|2015-07-07|2018-12-04|Thales|Method for integrating a constrained route optimization application into an avionics onboard system with open architecture of client server type|
    US10154096B2|2015-07-07|2018-12-11|Thales|Method for integrating a new service into an avionics onboard system with open architecture of client-server type, in particular for an FIM manoeuvre service|
    US11093868B2|2018-03-08|2021-08-17|Jetsmarter Inc.|Client creation of conditional segments|US20040100982A1|1999-09-30|2004-05-27|Sivaram Balasubramanian|Distributed real-time operating system|
    FR2818769B1|2000-12-21|2004-06-18|Eads Airbus Sa|MULTI-TASK REAL-TIME OPERATION METHOD AND SYSTEM|
    FR2819598B1|2001-01-16|2003-04-11|Thomson Csf|FAULT-TOLERANT SYNCHRONIZATION DEVICE FOR A REAL-TIME COMPUTER NETWORK|
    FR2882165B1|2005-02-11|2007-06-29|Airbus France Sas|SYSTEM AND METHOD FOR ONBOARD FLIGHT TEST PROCESSING|
    JP4074296B2|2005-03-25|2008-04-09|株式会社東芝|Schedulability determination method, real-time system, and program|
    NZ544381A|2006-03-02|2008-10-31|Airways Corp Of New Zealand|System and method for modelling a flight and invoicing the flight providers for services used|
    DE102006010400A1|2006-03-03|2007-09-06|Dspace Digital Signal Processing And Control Engineering Gmbh|Method for creating an optimized schedule for a time-controlled distributed computer system|
    US8321558B1|2009-03-31|2012-11-27|Amazon Technologies, Inc.|Dynamically monitoring and modifying distributed execution of programs|
    US8584124B2|2010-04-20|2013-11-12|Salesforce.Com, Inc.|Methods and systems for batch processing in an on-demand service environment|
    US20120271949A1|2011-04-20|2012-10-25|International Business Machines Corporation|Real-time data analysis for resource provisioning among systems in a networked computing environment|
    US8621473B2|2011-08-01|2013-12-31|Honeywell International Inc.|Constrained rate monotonic analysis and scheduling|
    US8924976B2|2011-08-26|2014-12-30|Knu-Industry Cooperation Foundation|Task scheduling method and apparatus|
    EP2568346B1|2011-09-06|2015-12-30|Airbus Operations|Robust system control method with short execution deadlines|
    US9639401B1|2014-05-08|2017-05-02|Rockwell Collins, Inc.|Multicore adaptive scheduler|US8744367B2|2010-08-31|2014-06-03|At&T Intellectual Property I, L.P.|Tail optimization protocol for cellular radio resource allocation|
    US8527627B2|2010-12-14|2013-09-03|At&T Intellectual Property I, L.P.|Intelligent mobility application profiling with respect to identified communication bursts|
    US9220066B2|2011-06-20|2015-12-22|At&T Intellectual Property I, L.P.|Bundling data transfers and employing tail optimization protocol to manage cellular radio resource utilization|
    US9264872B2|2011-06-20|2016-02-16|At&T Intellectual Property I, L.P.|Controlling traffic transmissions to manage cellular radio resource utilization|
    FR3025385B1|2014-09-01|2016-08-12|Thales Sa|METHOD FOR EXECUTING ADAPTIVE REAL-TIME SERVICES, IN PARTICULAR FLIGHT MANAGEMENT, AND REAL-TIME SYSTEM USING SUCH A METHOD|
    US9678773B1|2014-09-30|2017-06-13|Amazon Technologies, Inc.|Low latency computational capacity provisioning|
    US9600312B2|2014-09-30|2017-03-21|Amazon Technologies, Inc.|Threading as a service|
    US9830193B1|2014-09-30|2017-11-28|Amazon Technologies, Inc.|Automatic management of low latency computational capacity|
    US9413626B2|2014-12-05|2016-08-09|Amazon Technologies, Inc.|Automatic management of resource sizing|
    US9910713B2|2015-12-21|2018-03-06|Amazon Technologies, Inc.|Code execution request routing|
    US11132213B1|2016-03-30|2021-09-28|Amazon Technologies, Inc.|Dependency-based process of pre-existing data sets at an on demand code execution environment|
    US10684933B2|2016-11-28|2020-06-16|Sap Se|Smart self-healing service for data analytics systems|
    WO2018235124A1|2017-06-19|2018-12-27|三菱電機株式会社|Distributed allocation device, distributed allocation system, and distributed allocation method|
    US10831898B1|2018-02-05|2020-11-10|Amazon Technologies, Inc.|Detecting privilege escalations in code including cross-service calls|
    US10991255B2|2018-04-05|2021-04-27|Ge Aviation Systems Llc|Providing an open interface to a flight management system|
    US11146569B1|2018-06-28|2021-10-12|Amazon Technologies, Inc.|Escalation-resistant secure network services using request-scoped authentication information|
    US10949237B2|2018-06-29|2021-03-16|Amazon Technologies, Inc.|Operating system customization in an on-demand network code execution system|
    US11099870B1|2018-07-25|2021-08-24|Amazon Technologies, Inc.|Reducing execution times in an on-demand network code execution system using saved machine states|
    US11099917B2|2018-09-27|2021-08-24|Amazon Technologies, Inc.|Efficient state maintenance for execution environments in an on-demand code execution system|
    US11243953B2|2018-09-27|2022-02-08|Amazon Technologies, Inc.|Mapreduce implementation in an on-demand network code execution system and stream data processing system|
    CN109713736B|2018-12-30|2021-11-12|西北工业大学|Aircraft electric load distribution method based on dynamic database|
    US11010188B1|2019-02-05|2021-05-18|Amazon Technologies, Inc.|Simulated data object storage using on-demand computation of data objects|
    US11119809B1|2019-06-20|2021-09-14|Amazon Technologies, Inc.|Virtualization-based transaction handling in an on-demand network code execution system|
    US11190609B2|2019-06-28|2021-11-30|Amazon Technologies, Inc.|Connection pooling for scalable network services|
    US11115404B2|2019-06-28|2021-09-07|Amazon Technologies, Inc.|Facilitating service connections in serverless code executions|
    US11159528B2|2019-06-28|2021-10-26|Amazon Technologies, Inc.|Authentication to network-services using hosted authentication information|
    US11119826B2|2019-11-27|2021-09-14|Amazon Technologies, Inc.|Serverless call distribution to implement spillover while avoiding cold starts|
    US11188391B1|2020-03-11|2021-11-30|Amazon Technologies, Inc.|Allocating resources to on-demand code executions under scarcity conditions|
    法律状态:
    2015-05-08| PLFP| Fee payment|Year of fee payment: 2 |
    2015-11-20| PLSC| Search report ready|Effective date: 20151120 |
    2016-04-26| PLFP| Fee payment|Year of fee payment: 3 |
    2017-04-27| PLFP| Fee payment|Year of fee payment: 4 |
    2018-05-01| PLFP| Fee payment|Year of fee payment: 5 |
    2019-04-29| PLFP| Fee payment|Year of fee payment: 6 |
    2020-05-05| PLFP| Fee payment|Year of fee payment: 7 |
    2021-04-26| PLFP| Fee payment|Year of fee payment: 8 |
    优先权:
    申请号 | 申请日 | 专利标题
    FR1401108A|FR3021108B1|2014-05-16|2014-05-16|METHOD FOR REAL-TIME SERVICE EXECUTION, IN PARTICULAR FLIGHT MANAGEMENT, AND REAL-TIME SYSTEM USING SUCH A METHOD|FR1401108A| FR3021108B1|2014-05-16|2014-05-16|METHOD FOR REAL-TIME SERVICE EXECUTION, IN PARTICULAR FLIGHT MANAGEMENT, AND REAL-TIME SYSTEM USING SUCH A METHOD|
    EP15248011.7A| EP2945062A1|2014-05-16|2015-04-03|Method for performing services in real time, in particular flight management and real-time system implementing such a method|
    CA2888897A| CA2888897C|2014-05-16|2015-04-22|Method for the execution of services in real time flight management system|
    US14/696,132| US9967322B2|2014-05-16|2015-04-24|Method for the execution of services in real time flight management system|
    [返回顶部]